Florian Müllner [Thu, 16 Oct 2025 20:48:21 +0000 (22:48 +0200)]
ci: Reinstall gdk-pixbuf2 package
The mutter image contains a custom gdk-pixbuf build without the
glycin loader, in order to unbreak running installed tests in CI.
The downside is that we end up with no SVG loader. For the toolbox
image we don't care about installed tests, but we very much care about
working icons.
So reinstall the distro gdk-pixbuf package to bring back the glycin
loader (and thus SVG support).
Davide Ferracin [Tue, 7 Oct 2025 12:45:45 +0000 (14:45 +0200)]
i18n: Add context to "Power mode" title string
The "Power mode" string in the quick settings menu appears both in the
title of the button and as the menu header that opens when clicking on
such button.
Currently they are translated together, but---at least in
Italian---the standard translation, "Modalità energia", is too long to
fit in the button and is very often truncated to "Modalità…" (aka
"Mode", in English) from which is not clear what the menu is about.
We would use "Energia" for the button title, but at the same time it
would be nice to have the full "Modalità energia" translation in the
menu header, where there is more space available.
For this reason I propose to add contexts to the two "Power mode"
strings, so that the string can be translated in different ways
depending on its position.
Florian Müllner [Wed, 1 Oct 2025 18:19:14 +0000 (20:19 +0200)]
messageList: Make media messages follow notification policy
Unlike regular notifications, media messages are shown unconditionally
for any active MPRIS player. In the past that was uncontroversial, but
now that media messages are shown on the lock screen as well, there is
a privacy concern.
To address this, make media messages follow the notification policy
of the corresponding app (if specified) or the general notification
settings.
messageTray: Never close a notification banner that is about to show
If a new notification is pushed (or the same is updated) in a very short
time GNOME shell may only show the last notification (or none).
This is because since commit 2801d0bf a notification that is about to
show (so in SHOWING state) may be considered expired, given that the
notification timeout won't be set until the show animation has
completed.
Thus, only consider the notification as expired when the notification is
in the shown state, but not in the showing one.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6529 Fixes: 2801d0bfe3 ("messageTray: Close SHOWING banner when its notification is destroyed")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3905>
notificationDaemon: Do not send activation event multiple times
When a FDO notification is updated we reuse the previous instance,
however we do not care about disconnecting the default activation signal
and thus we may end up emitting the same multiple times, even in the
case the updated notification has no action at all.
Carlos Garnacho [Tue, 30 Sep 2025 14:09:47 +0000 (16:09 +0200)]
status/keyboard: Track ::layout-layout-group-changed for changes
This may happen under the hood without UI interaction through modifiers
expressed in xkb-options to switch to specific layouts. Make this
actually have an effect in the UI bits, and update the selected layout
if these changes happen without further GNOME Shell involvement.
The end session dialog is now using a new style for the warning messages
but this style is not re-used by other dialogs that have messages with a
similar role.
So be consistent, and use same style for all the dialogs that are
showing a warning or an info message, and in particular
- Keyring dialog error messages
- Polkit dialogs error and info messages
- Conflicting dialog warning message
Daniel van Vugt [Fri, 26 Sep 2025 06:36:41 +0000 (14:36 +0800)]
st/theme-context: Warn instead of crashing on unsupported accent colors
For example, Ubuntu's "brown". This is patched into gnome-shell for Ubuntu
but if you forget the patch then it's not worthy of a crash. Just pick a
colour and issue a warning.
notificationDamon: Always send the activation token
In case of FDO notifications, we may receive a notification coming from
non-desktop-applications (e.g. gsd does that), but in any case when
activating an action we should always provide back the activation-token.
So send the startup notification ID in any case, even if the appId is
unset (in fact get_startup_notify_id() uses a nullable parameter for a
reason since GNOME/glib@6210708f).
In wayland this more than enough, while in X11 we could have used the
gnome-shell desktop file as fallback, but that's gone for good now!
Noam Raz [Wed, 24 Sep 2025 08:49:43 +0000 (11:49 +0300)]
overviewControls: Ensure ws thumbnails are expanded before fading in
The current logic in `_updateThumbnailsBox` updates the expand fraction
only after the fade animation completes, rendering the fade-in
transition broken: the thumbnails fade in, but they have a height of 0
until after the animation, when they jarringly "pop" into place. This
abrupt transition is observable when exiting search in the overview with
multiple active workspaces.
Instead, split up the logic a bit to make sure the thumbnails always
appear fully-expanded during the animation: when animating in, the
`expand-fraction` is set _before_ the animation starts, and when
animating out it is set after.
This logic should make all workspace thumbnail state transitions behave
correctly:
- The thumbnails still expand/collapse smoothly when `should-show`
changes because `_updateThumbnailsBox` is called only when that
transition completes.
- Transitions into/out of search just fade the thumbnails because they
are always expanded during the animation.
- https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7668 is avoided
because `expand-fraction` is still set to 1 by `_updateThumbnailsBox`
when revealing the thumbnails.
- The thumbnails still have an `expand-fraction` of 0 when hidden,
carrying over the fixes from 9bf550da8 ("overviewControls: Set
expandFraction for ws thumbnails to 0 when hidden").
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7985 Fixes: c576f82bd ("overviewControls: Make sure thumbnails expandFraction is bound to visibility")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3888>
gdm/authPrompt: Fix key focus handling on choice list
When a choice list widget is prompted in GDM we call updateSensitivity()
but this does not act on the currently visible authentication widget but
rather on the text entry all the times.
And this causes that when a choice list is shown we always set the key
focus to the (hidden) text entry.
This implies that when the list is finally shown, moving the arrow keys
leads makes the entry context menu to be shown instead of being able to
navigate through the entries.
So, make updateSensitivity use the currently visible authorization
widget instead and use it to control the sensitivity of the choice list
As per previous change we now rely on a GLib version in which GioUnix
DesktopAppInfo implementation provides all the methods, so let's bump
the glib (actually gio) dependency for that.
As we need to be sure that the shell's typelib is rebuilt against newer
Gio, or updating GLib before than the shell would break us.
While introducing latest malcontent in the toolbox, mistakenly wrong
path to install-meson-project.sh was used. Correct this by using the
proper path, after copying the script there.
Moreover, disable building documentation in malcontent subproject
libgsystemservice, so that we don't have to install more dependencies.
Fixes: b7992b80 ("ci: Include latest malcontent in the toolbox")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3873>
The build-toolbox job only runs for main and stable branches, so
we currently only know whether modifications to the build-toolbox
script actually work once they a merged.
To catch errors up-front, do test builds of the toolbox image
when a merge request modifies the build script.
A race condition can occur where a notification banner gets stuck on screen
and never disappears.
This happens when a new notification needs to be shown while an old one
is in the middle of its hiding animation. The process to show the new
notification calls `remove_all_transitions()`, which forcefully stops
the hiding animation of the old one.
The cleanup logic, which destroys the old banner actor, was located in
the `onComplete` handler of the animation. Since the animation was
interrupted and not completed, this handler was never called, leaving a
"zombie" banner on screen.
To fix this, the call to the cleanup function is moved from the
`onComplete` handler to an `onStopped` handler. This handler is
guaranteed to be called whenever an animation stops, regardless of
whether it finished successfully or was interrupted. This ensures the
banner is always cleaned up correctly.
Carlos Garnacho [Fri, 12 Sep 2025 13:28:09 +0000 (15:28 +0200)]
pointerA11yTimeout: Protect against destroyed PieTimer actor
This trigger an exception if the PieTimer destroys itself before the
ClutterSeat::ptr-a11y-timeout-stopped signal triggers. It's unlikely
to happen now with the fixed arguments, but still makes sense for
correctness.
Carlos Garnacho [Fri, 12 Sep 2025 13:22:31 +0000 (15:22 +0200)]
pointerA11yTimeout: Adapt to API changes in Mutter
https://gitlab.gnome.org/GNOME/mutter/-/commit/76166d61 did sneak
in an API change by removing the ClutterInputDevice arguments from
the ClutterSeat::ptr-a11y-timeout-* signals. Through a series of
astonishing coincidences, we don't use those arguments, so just
remove them. Since the rest of the arguments were shifted, this
fixes broken behavior of the PieTimer.
docs: Replace references to --nested with --devkit
The --devkit option is strongly recommended over the old --nested
nowadays, not least because the latter option no longer exists by
default (as it is tied to the X11 backend).
Remove the section on global shortcuts and workaround for looking glass,
as Devkit supports inhibiting keyboard shortcuts.
ci: Start with a fresh build dir to ensure test dependencies are correct
We want to ensure that meson test just works, without having to redo the
whole dependencies setup phase, so let's just start a new fresh build dir
and run tests there
Ideally meson tests should just work without any pre-requisite build,
instead, we only need a configured build folder to work, but this does
not go as expected in gnome shell at the moment.
Since tests require generated files and compiled typelibs they don't
depend on, so just using `meson test -C build <test-name>` does not work
as expected.
So add test dependencies on test cases. We do not need to have per-test
dependencies right now since most of them share just the same
requirements, and this makes it easier to maintain
Currently the toolbox lacks malcontent >= 0.14.0, because that version
has not been released yet. However, we need it to test the upcoming
parental controls integration, so build it in the toolbox.
Pranav Jerry [Sun, 31 Aug 2025 14:09:02 +0000 (19:39 +0530)]
po/ml: Fix wrong calendar date formats
Closes: https://gitlab.gnome.org/Teams/Translation/ml/-/issues/1 Signed-off-by: Mohammed Sadiq <sadiq@sadiqpk.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3856>
Sebastian Wick [Mon, 8 Sep 2025 11:19:21 +0000 (13:19 +0200)]
brightnessManager: Handle absence of brightness control in _sync
We already call _sync in response to dimming changes, which might happen
no matter if we actually do have control over the brightness.
Let's just embrace _sync getting called in any situation and handle that
state gracefully by simply returning early. If we re-gain control, _sync
will be called again and the updated state becomes active.
An St.Button with toggle-mode ON would not update the toggle state when
invoked via keyboard input.
Fixes: dd694bf1a ("st/button: Use ClutterClickGesture instead of own button-press tracking")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3865>
Jonas Ådahl [Fri, 5 Sep 2025 13:53:52 +0000 (15:53 +0200)]
popupMenu: Queue relayout on popup menu parent when opening
The position of the menu depends on the position of the "source actor",
but the source actor is not a parent of the menu, but typically a
sibling.
Since we depend on the source actor position for placing the popup menu,
it's important that the source actor gets allocated before we allocate.
Currently the only way to ensure that the source actor is allocated
before the popup menu is by handling the layout via the parent actor, as
the order of the allocations done when queuing shallow relayouts is
currently undefined. As of d94638acae ("clutter/actor: Make child
position changes a noop when possible") in mutter,
Clutter.Actor.set_child_above_sibling() has a fast path when the
position doesn't change, which means the parent was did not get its
relayout queued. This caused the popup menu to end up being allocated
before the source actor, thus using an out of date source actor
allocation to base its position calculation on.
To fix this, queue a relayout on the parent actor unconditionally, after
inserting it into the parent actor, to let us be able to rely on the
source actor having been allocated before the popup menu itself getting
allocated.
Jonas Dreßler [Thu, 24 Jul 2025 16:27:29 +0000 (18:27 +0200)]
st/theme-context: Run dispose on theme nodes on theme context changes
When the theme context changes, we clear the theme cache and make the
widget tree throw away and create new theme nodes. That's because the
old theme nodes can no longer be used, they might be referencing old
CSS data, scale factors, or other things.
St itself should never reuse theme nodes after theme context changes,
but of course theme nodes are exposed to users of St, and they can
always keep a theme node around and call a method on it even after a
theme context change.
To avoid those outdated theme nodes accessing outdated pointers into
the Croco structures and causing crashes, force-run their `dispose()`
function when the theme context changes. This should ensure that all
problematic pointers in the theme nodes are cleared, and users of St
can't crash gnome-shell.
Jonas Dreßler [Thu, 24 Jul 2025 17:47:58 +0000 (19:47 +0200)]
st/theme-node: Free properties array on dispose rather than finalize
We're going to use `g_object_run_dispose()` on StThemeNode with the next
commit in order to manually clear the properties array and a few other
things when the StThemeContext changes.
That's because after theme context changes, the CSS properties will no
longer be valid, and accessing them will cause crashes. Even if St behaves
nicely and throws out all theme nodes on theme context changes, there
might still be users holding references to nodes, so we want to ensure that
the old nodes are harmless after theme context changes.
Jonas Dreßler [Thu, 24 Jul 2025 16:51:25 +0000 (18:51 +0200)]
st/widget: Don't animate theme node updates on theme context changes
With commit 4dfa39457e, I was assuming that emitting `::changed` on the
StThemeContext, triggering StWidgets recursive style-changed machinery,
is enough to get rid of all the theme nodes that are in use, ensuring
they're never accessed again after the `::changed` emission.
That assumption turned out to be wrong: `st_widget_recompute_style()`
animates updates of theme nodes using StThemeNodeTransition, and
StThemeNodeTransition keeps the old theme node around, accessing it at
various later points. This caused various crashes on extension
loading/unloading, because that triggers a theme context change, where
a StThemeNodeTransition would later access an outdated theme node,
pointing to CSS properties that are already freed.
That said, reverting 4dfa39457e doesn't seem like the best idea,
because other calls to `st_theme_context_changed()` also seem to make
the same (incorrect) assumption, eg. `st_theme_context_set_theme()`
seems like a good candidate for a similar crash.
Probably St just shouldn't try to animate on theme context changes: The
old theme nodes are no longer usable after those, but
StThemeNodeTransition expects them to be, so that's just a bad idea.
So change the style-changed machinery a bit to allow disabling transitions
and use that to avoid transitions on theme context changes.
Fixes: 4dfa39457e ("st/theme-context: Also remove theme nodes on stylesheet changes") Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7339
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3809>
status/network: Update Wi-Fi quicksettings icon on disconnect
Prior to this patch, upon a connected AP disconnecting from
the device, the current quicksettings wi-fi icon will continue
showing the "network-wireless-connected-symbolic" symbol in
the time between the initial disconnection and the adapter
deactivation, even though the connection has been
degraded by virtue of no longer being routable.
This will also happen in the
NM.ActiveConnectionState.DEACTIVATING state.
To make this clearer to the user, this change modifies
quicksettings' wifi icon to reflect the degraded states:
- An activated adapter with no active AP connection will
now map to the network-wireless-offline-symbolic icon
(to indicate that the AP signal is lost)
- NM.ActiveConnectionState.DEACTIVATING will now map to the
network-wireless-acquiring-symbolic icon (to indicate that
a state transition is in progress)
projects / gnome-shell.git / log